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Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Dear Sir: 

Applicants request review of the final rejection in the above-identified application. No 
amendments are being filed with this request. 

This request is being filed with a Notice of Appeal. 
The review is requested for the reasons stated below. 



Examiner Failed to Show Teachings for Several Claim Limitations and Sufficient 
Motivation to Modify such Teachings 

The final Office Action dated November 24, 2006 rejected claims 1-4, 8, 11-15, 19, 22- 
25, 30, 33 and 34 under 35 U.S.C. 102(b) as being anticipated by Perlman (U.S. Publication 
2002/0135696; hereinafter "Perlman"), claims 7, 18 and 29 under 35 U.S.C. 103(a) as being 
unpatentable over Perlman in view of Naegle (U.S. Publication 2004/0012577; hereinafter 
"Naegle") and claims 9, 20 and 31 under 35 U.S.C. 103(a) as being unpatentable over Perlman. 



REMARKS 
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It is respectfully submitted that the cited references, either individually or in combination, do not 
disclose every limitation recited in the pending claims. 

Specifically, with respect to independent claims 1, 12 and 23, the cited references and 
particularly Perlman do not disclose at least the following recited limitation: synchronizing each 
converted data stream to an output frame rate consistent with the first set of display attributes. In 
other words, Perlman does not disclose the use of my frame rate conversion to synchronize the 
source material to a frame rate consistent with the display, because Perlman requires an ad hoc 
correction (flicker filter) to be applied in order to reduce image flicker when displaying 
progressive images on an interlaced display. 

Referring to paragraphs [0027]-[0028] and Fig. 3B of Perlman, if the display is 
interlaced, and some of the source content is not interlaced (i.e., progressive scan), then Perlman 
displays the progressive scan source material on an interlaced display concurrently with the 
interlaced source material. Perlman requires that a flicker filter must be applied in order to 
reduce image flicker when displaying progressive images on an interlaced display since 
interlaced displays refresh, or update their images, at a significantly slower rate (i.e., frame rate) 
than personal computer displays. Therefore, not only does Perlman not convert the incoming 
source material to a format consistent with the display (Perlman displays progressive scan source 
material on an interlaced display), Perlman must then provide an ad hoc correction (flicker filter) 
since there is no frame rate conversion used to synchronize the source material to a frame rate 
consistent with the display as is required by the invention (i.e., since there is no frame rate 
conversion performed to synchronize the source material to the display and interlaced displays 
refresh, or update their images, at a significantly slower rate than personal computer displays, a 
noticeable flicker will occur due to the mismatch in the frame rate of the video and the refresh 
rate of the display). 

In contrast, the instant application specifically requires a frame rate converter to 
synchronize each converted data stream to be consistent with the display screen thereby 
obviating the need for a flicker filter. For example, independent claim 1 recites that the video 
processor comprises, in part, a number of configurable image converter units each coupled to an 
associated one of the ports for converting the corresponding input video stream to a 
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corresponding converted video stream having the single display video format; and a configurable 
frame rate conversion unit configured to synchronize each converted data stream to an output 
frame rate consistent with the first set of display attributes. Similarly limitations are recited in 
independent claims 12 and 23. 

The final Office Action states that one skilled in the art would recognize a de-interlacer to 
change rate of video, and this de-interlacer is "interpreted as some sort of line doubler." The 
final Office Action argues that, "since, in interlaced format, a frame is equal to two fields, by de- 
interlacing, the frame rate is doubled." This assertion is respectfully traversed. 

Progressive scan and interlaced scan are two commonly used methods for displaying an 
image or video on a television screen. With "progressive scan," the lines are drawn one at a time 
in sequential order (see "http://www.webopedia.eom/TERM/p/progressive_scan.html"). In 
contrast, interlaced scan uses two fields to create a frame, with one field containing all the odd 
lines in the image and the other field containing all the even lines of the image (see 
"http://www.webopedia.eom/TERM/I/interlaced_scan.html"). Typically, with interlaced scan, 
60 fields (30 odd and 30 even) are scanned every second, and the two sets of 30 fields are 
combined to create a full frame every 1/30* second, resulting in a display of 30 frames per 
second. On the other hand, with progressive scan, the entire single frame image is painted every 
l/30 th , 1/60* of a second and so on eliminating interlacing artifacts (such as mis-match between 
odd/even lines resulting in "jaggies"). Because of the different methods for handling the video 
between progressive scan and interlaced scan, an interlaced video cannot be displayed on a 
progressive display device in its native format but requires a de-interlaced process to be 
performed on the interlaced video first, and vice versa. 

As explained in the Office Action Response titled "Amendment G" filed on February 14, 
2007, de-interlacing does not change the frame rate of the video source. In this respect, it 
appears that the Examiner has confused the concept of "frame rate" with the concept of "field 
rate." On the one hand, frame rate is the number of complete frames per second (fps) in the 
video stream. Both interlaced video and progress scan video have frame rates. On the other 
hand, field rate is a concept that only applies to interlaced video. When a video stream is 
interlaced, each frame is scanned first with odd lines, then with even lines. Such scan of every 
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second line is called a "field." Thus, odd lines are called "odd field," and even lines are called 
"even field." Field rate refers to the number of odd or even fields per second in the interlaced 
video stream (see http://en.wikipedia.org/wiki/Interlaced). For example, assume a video stream 
has a frame rate of 30 fps. After this video stream is interlaced into odd and even fields, it has a 
field rate of 60 fields-per-second. However, its frame rate does not change and remains at 30 
frames-per-second. 

Furthermore, one skilled in the art understands that de-interlacing is "the process of 
converting interlaced video (a sequence of fields) into a non-interlaced form (a sequence of 
frames)" (see http://en.wikipedia.org/wiki/De-interlacing). Although de-interlacing is sometimes 
referred to as "line doubling," there are many different types of de-interlacing algorithms. 
Broadly speaking, de-interlacing methods may be categorized into two large groups: 
combination, where the even and odd frames are combined into one image and then displayed, 
and extension, where each frame (with only half the lines) is extended to the entire screen. 
Regardless of which de-interlacing algorithm is used, the frame rate of the video stream does not 
change after the de-interlacing process. 

The final Office Action further indicates that a progressive image displayed on an 
interlaced display is inherently interlaced. This assertion is respectfully traversed. When a 
progressive image is displayed on an interlaced display in its native un-interlaced format, the 
image is distorted. This is why the image needs to be interlaced before it is sent to the interlaced 
display device. Interlacing is not done automatically whenever a progressive image is sent to an 
interlaced display. It must be performed as a separate step. Similarly, when an interlaced video 
is sent to a progressive scan display device, the interlaced video needs to be de-interlaced before 
it may be displayed on the progressive display device. The de-interlacing process is an 
additional step separate from the display process. 

Moreover, the Examiner also notes that "an interlaced display can only display half of its 
vertical resolution at a time, followed by the other half. Since an image displayed in this manner, 
even if distorted, is inherently divided into fields, this reads on the definition of an interlaced 
image". In effect, the Examiner admits that any attempt to display a progressive scan signal on 
an interlaced display will result in a distorted image and is therefore results in an inoperable 
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combination of displaying a progressive scan signal on an interlaced display that decidedly 
teaches away from the invention. 

In the Advisory Action dated February 27, 2007, the Examiner notes that a line doubler 
does not necessarily discard every other field and specifically points to 

http:www.hdtvmagazine.com/glossary.php" as reference. However, at no point does the cited 
reference describe a line doubler creating a progressive 60 frame per second signal from an 
interlaced 30 frame per second signal as would be the case if the Examiner was correct in his 
presumption. On the contrary, the reference describes using frame rate conversion to convert a 
1080p/24fps (frame per second) signal to either a progressive 1080p/60 fps (an example of pure 
frame rate conversion) or 1080i/30 fps (30 fps is equal to 60 fields per second), which is an 
example of frame rate conversion (24 fps to 30 fps) and interlacing (1080p to 1080i) and not line 
doubling as suggested by the Examiner. As a matter of fact, converting 1080p to 1080i results in 
the number of full display lines being halved (i.e., 1080i = 540p) resulting in 50% of the 
information originally included in the 1008p signal being discarded. Therefore, the Examiner by 
citing this reference corroborates the Applicant's previous discussion regarding frame rate 
conversion. To reiterate, since Perlman does not teach frame rate conversion as taught by claim 
1, Perlman must use a flicker filter to eliminate the "objectionable flicker". At no point does 
Perlman rely upon any form of frame rate conversion as discussed by the reference cited by the 
Examiner. 

In view of the foregoing, it is respectfully submitted that the rejections of all pending 
claims should be withdrawn. 

Respectfully submitted, 
BEYER WEAVER LLP 

/Michael J. Ferrazano/ 
Michael J. Ferrazano 
Reg. No. 44,105 

P.O. Box 70250 
Oakland, CA 94612-0250 
408-255-8001 



Application No.: 10/707,074 



5 



Atty. Dkt. No.: GENSP052 



